9장. 추론 최적화
출처: 『AI 엔지니어링』(Chip Huyen 저, 한국어판) | O'Reilly 2024 | pp. 472–518 | 9장 원본 텍스트 v9 reviewed 기반
모델이 아무리 훌륭해도 너무 느리거나 비싸면 실용 가치가 없다. 추론 최적화는 모델·하드웨어·서비스 세 수준에서 지연 시간과 비용의 병목을 제거하는 융합 분야다. 이 장은 자기회귀 언어 모델의 추론 구조를 해부하고, KV 캐시·양자화·배칭·병렬화·추측 디코딩 등 핵심 기법의 원리와 트레이드오프를 다룬다.
학습 목표
이 장을 끝내면 다음을 할 수 있다.
- 추론 작업의 병목(연산 제약 vs 메모리 대역폭 제약)을 루프라인 차트로 진단할 수 있다.
- TTFT와 TPOT 지표를 분석해 프리필·디코딩 단계별 성능 측정 및 개선 방안을 수립할 수 있다.
- 양자화·KV 캐시·추측 디코딩·플래시 어텐션·연속 배칭 등 핵심 최적화 기법의 원리와 트레이드오프를 설명할 수 있다.
- 복제·텐서·파이프라인 병렬 처리 전략을 지연 시간·처리량·모델 크기 조건에 따라 선택하고 설계할 수 있다.
- 온라인 API와 배치 API의 차이를 설명하고, 적합한 사용 사례를 구분할 수 있다.
전체 흐름도
이 장의 핵심은 "어떤 병목이 있고, 어느 수준에서 어떤 기법으로 제거하는가"다.
[ 학습된 모델 ]
│ 추론 요청 (입력 토큰)
▼
[ 프리필 단계 ] ← 연산 제약 (compute-bound)
│ 입력 전체를 한 번에 병렬 처리 → TTFT 결정
▼
[ 디코딩 단계 ] ← 메모리 대역폭 제약 (memory bandwidth-bound)
│ 토큰을 하나씩 자기회귀 생성 → TPOT 결정
▼
[ 최적화 기법 (세 수준) ]
│
├─ 모델 수준
│ ├─ 양자화 (FP32→INT8·INT4: 메모리·대역폭 절감)
│ ├─ 지식 증류 (교사→학생 모델: 크기 절감)
│ ├─ 프루닝 (불필요 파라미터 제거: 희소화)
│ ├─ 어텐션 재설계 (MQA·GQA·크로스 레이어·로컬 윈도우)
│ └─ 자기회귀 가속 (추측 디코딩·참조 기반 추론·병렬 디코딩)
│
├─ 하드웨어·커널 수준
│ ├─ GPU/추론 전용 칩 선택
│ ├─ 커널 최적화 (FlashAttention, 연산자 융합, 벡터화, 병렬화, 루프 타일링)
│ └─ 컴파일러 최적화 (torch.compile, TensorRT, Apache TVM)
│
└─ 서비스 수준
├─ 연속 배치 처리 (처리량 2~3배)
├─ 프리필·디코딩 분리 (TTFT·TPOT 동시 개선)
├─ KV 캐시·페이지드 어텐션 (메모리 효율)
├─ 프롬프트 캐싱 (반복 시스템 프롬프트 절감)
└─ 병렬화 전략 (복제·텐서·파이프라인·컨텍스트·시퀀스)
│
▼
[ 서빙 산출물 ]
지연 시간 (TTFT + TPOT) 감소 & 처리량(Throughput) 증가
→ 비용 절감 + 사용자 경험 향상
0. 사전 필수 용어
참고 — 이 장은 2장에서 다룬 프리필·디코딩 두 단계를 전제로 한다. 트랜스포머 추론 흐름을 이미 알면 §1로 바로 넘어가도 좋다.
- 추론(Inference) — 학습된 모델에 입력을 넣어 결과를 얻는 과정. 학습(역전파 포함)과 달리 순전파만 실행한다.
- 추론 서버(Inference Server) — 운영 환경에서 모델 추론을 실행하는 구성 요소. 여러 모델을 호스팅하고, 요청을 받아 리소스를 할당해 처리한다.
- 추론 서비스(Inference Service) — 추론 서버를 포함한 더 큰 시스템. 요청을 받아 적절한 곳으로 전달하고, 추론 서버 도달 전 전처리를 담당한다.
- 지연 시간(Latency) — 사용자가 요청을 보낸 시점부터 완전한 응답을 받기까지 걸리는 시간. TTFT와 TPOT의 합으로 분해된다.
- 처리량(Throughput) — 추론 서비스가 초당 생성하는 출력 토큰 수(tokens/s). 비용과 직결된다.
- KV 캐시(KV Cache) — 디코딩 단계에서 이전 토큰의 키(K)·값(V) 벡터를 저장해 반복 계산을 피하는 메모리 구조.
- 메모리 대역폭 제약(Memory Bandwidth Bound) — 작업 속도가 메모리와 프로세서 간 데이터 전송 속도에 의해 결정되는 상태. 자기회귀 디코딩은 대표적인 메모리 대역폭 제약 작업이다.
- 산술 강도(Arithmetic Intensity) — 메모리 1바이트에 접근할 때 수행하는 산술 연산 횟수. 연산 제약 vs 메모리 대역폭 제약을 구분하는 수학적 기준이다.
1. 추론 최적화의 배경과 범위
추론 최적화는 모델 연구자·애플리케이션 개발자·시스템 엔지니어·컴파일러 설계자·하드웨어 아키텍트·데이터센터 운영자까지 함께 작업하는 융합 분야다. 아무리 성능이 뛰어난 모델도 응답이 이틀이 걸린다면 예측 결과는 이미 쓸모없어진다. 주가 예측 모델이 결과를 계산하는 데 이틀이 걸린다면, 또 모델이 너무 비싸면 투자 대비 효과가 없어진다.
최적화의 세 수준. 모델 수준은 모델 자체를 수정한다(양자화·증류·프루닝·어텐션 재설계). 하드웨어 수준은 더 성능 좋은 가속기를 설계하거나 선택한다. 서비스 수준은 주어진 하드웨어에서 모델을 운영하는 방식을 개선한다(배칭·병렬화·캐싱).
두 가지 연산 병목. 연산 제약(compute-bound)은 작업 완료 시간이 수행해야 할 연산량에 의해 결정된다. 메모리 대역폭 제약(memory bandwidth-bound)은 메모리와 프로세서 간 데이터 전송 속도에 의해 결정된다. 루프라인 차트로 어느 병목인지 진단할 수 있다(Williams et al., 2009 — Roofline 논문). 트랜스포머 기반 언어 모델의 프리필은 연산 제약이고, 자기회귀 디코딩은 메모리 대역폭 제약이다.
용어 주의 — "메모리 제약"은 두 가지로 쓰인다. 시스템 쪽 출신은 대역폭 제약 의미로, AI 쪽 출신은 메모리 용량 제약 의미로 쓰는 경향이 있다. 메모리 용량 제한도 결국 데이터를 나눠야 해서 실제로는 대역폭 문제가 된다.
잘못된 이해:
"GPU 활용률(nvidia-smi) 100%면 효율적으로 돌아가고 있다"
→ nvidia-smi의 GPU 활용률은 단지 GPU가 작업을 처리하는 시간 비율이다. 초당 100개 연산 가능한 GPU가 1개만 처리해도 100%로 나올 수 있다.
올바른 접근:
MFU(Model FLOPs Utilization)와 MBU(Model Bandwidth Utilization)로 실질 효율을 측정한다.
온라인 API vs 배치 API. 많은 모델 제공업체가 두 종류의 추론 API를 제공한다. 온라인 API는 지연 시간을 최적화한다(고객 대면 챗봇·코드 자동 완성). 배치 API는 비용을 최적화한다. 집필 당시 기준으로 구글 제미나이와 OpenAI 모두 배치 API를 50% 할인된 가격에 제공하지만, 처리 시간은 초나 분 단위가 아닌 시간 단위로 걸린다.
배치 API가 적합한 사용 사례: 합성 데이터 생성 / 정기 보고서 작성(슬랙 메시지 요약·감정 분석·고객 지원 티켓 분석) / 신규 고객 온보딩 시 문서 처리 / 새 모델로의 데이터 재처리(마이그레이션) / 개인화 추천·뉴스레터 대규모 생성 / 지식 베이스 업데이트.
2. 추론 성능 지표
지연 시간 분해 — TTFT와 TPOT. 첫 토큰까지 걸리는 시간(TTFT, Time To First Token)은 프리필 단계에 해당하며 입력 길이에 따라 달라진다. 출력 토큰당 시간(TPOT, Time Per Output Token)은 첫 번째 토큰 이후 각 토큰이 얼마나 빨리 생성되는지 측정한다. 전체 지연 시간 = TTFT + TPOT × (출력 토큰 수)다. 스트리밍 모드에서 TPOT는 사람의 읽기 속도(빠른 독자 기준 토큰당 약 120ms, 초당 6~8개 토큰) 이하면 충분하다.
유사 지표로 토큰 간 시간(TBT, Time Between Tokens — 링크드인 사용)과 토큰 간 지연 시간(ITL — 엔비디아 사용)이 있다. 둘 다 출력 토큰 사이 걸리는 시간을 측정한다.
사용자가 경험하는 TTFT. 특히 CoT(생각의 사슬)나 에이전트 방식에서 모델이 내부적으로 중간 단계를 거칠 때, 사용자가 실제로 보는 첫 토큰까지의 시간은 모델 관점 TTFT보다 훨씬 길다. 일부 팀은 이를 "공개까지의 시간(Time to Publish)"이라 별도 지표로 추적한다.
지연 시간은 백분위수로 측정. 평균이 아닌 p50·p90·p95·p99로 보는 것이 중요하다. 네트워크 오류나 특별히 긴 프롬프트 처리 등 이상치 하나가 평균을 크게 왜곡할 수 있다. TTFT 값을 입력 길이별로 그래프로 그려보는 것도 진단에 도움이 된다.
처리량과 굿풋(Goodput). 처리량은 추론 서비스가 모든 사용자와 요청을 통틀어 초당 생성하는 출력 토큰 수(tokens/s)다. 일부 팀은 tokens/s/user 지표로 사용자 확장성을 평가한다. RPS(초당 요청 수)보다 RPM(분당 요청 수)이 파운데이션 모델에서 더 일반적으로 쓰인다. 처리량은 연산 비용과 직결된다. 처리량이 높을수록 비용이 낮다.
굿풋(goodput)은 SLO(소프트웨어 수준 목표)를 만족하는 초당 요청 수다. 처리량만 보면 실제 사용자 경험을 놓칠 수 있어 굿풋으로 보완한다. 예를 들어, 분당 100개 요청을 처리하지만 SLO(TTFT 200ms·TPOT 100ms)를 만족하는 게 30개뿐이라면 굿풋은 30 RPM이다.
트레이드오프 실측 — 링크드인 AI 팀(2024) 회고에 따르면, TTFT와 TPOT를 조금 희생하면 처리량을 2~3배까지 올릴 수 있는 경우가 많다.
활용률 — MFU와 MBU. MFU(Model FLOPs Utilization)는 이론적 최대 FLOP/s 대비 실제 토큰 처리량(tokens/s) 비율이다. MBU(Model Bandwidth Utilization)는 사용 가능한 이론적 대역폭 대비 실제 사용 대역폭 비율이다.
MBU 계산식:
MBU = (파라미터 수 × 파라미터당 바이트 × tokens/s) / (이론적 대역폭)
예: 7B 모델, FP16(2바이트), 초당 100토큰, A100(2TB/s)
→ 7B × 2 × 100 = 1,400 GB/s
→ MBU = 1,400/2,000 = 70%
연산 제약 작업은 MFU가 높고 MBU가 낮으며, 대역폭 제약 작업은 그 반대다. 학습 MFU 50% 이상이 집필 당시 기준으로 일반적으로 양호한 수준이다(GPT-3 175B V100에서 MFU 21.3%, PaLM 540B TPU v4에서 46.2% 등).
3. AI 가속기
CPU vs GPU. CPU는 강력한 코어 수십 개(소비자용 최대 64개)로 운영체제·I/O·복잡한 순차 프로세스에 특화됐다. GPU는 수천 개의 작고 상대적으로 약한 코어로 병렬 처리에 최적화됐다. ML 작업의 대부분은 행렬 곱셈(matmul)으로 이루어지며, 전체 부동소수점 연산의 90% 이상을 차지한다.
2012년 AlexNet이 GPU로 학습된 첫 번째 주요 딥러닝 모델 논문으로 유명해진 배경에는, 구글 당시 연구에서 동급 모델 학습에 수천 개의 CPU가 필요했으나 몇 개의 GPU만으로 가능해진 것이 있다.
가속기 평가 세 축 — 연산 성능·메모리·전력. 연산 성능은 FLOP/s로 측정하며 수치 정밀도(FP32·FP16·INT8·FP8)에 따라 달라진다. 칩 제조사가 내세우는 최대 FLOP/s에 "최대 FLOP/s 해킹"(희소 행렬 등 특수 조건 실험)이 있을 수 있어 실제 MFU 달성이 어려운 경우도 있다.
메모리는 크기와 대역폭으로 평가한다. GPU는 3단계 메모리 계층 구조를 갖는다: - CPU DRAM: 25~50 GB/s - GPU HBM(고대역폭 메모리): 256 GB/s~1.5 TB/s 이상 - GPU 온칩 SRAM: 10 TB/s 이상 (크기는 40MB 이하로 작음)
전력은 TDP(열 설계 전력) 또는 최대 전력 소모량으로 표시한다. 엔비디아 H100은 최대 성능으로 연간 약 7,000 kWh를 소비한다(미국 가정 연평균 전력 사용량 10,000 kWh 비교). 수만 개 GPU가 들어간 대규모 데이터센터 구축 시 전력 확보가 가장 큰 걸림돌이 되고 있다.
추론 전용 칩의 등장. 배포된 운영 AI 시스템에서 추론 비용이 ML 관련 비용의 최대 90%를 차지한다(Desislavov et al., 2023). 추론은 낮은 정밀도와 빠른 메모리 접근에 최적화되어 있어, 애플의 Neural Engine·AWS Inferentia·메타 MTIA·구글 엣지 TPU·엔비디아 Jetson Xavier처럼 추론 전용 칩이 설계되고 있다.
4. 모델 압축 — 양자화·증류·프루닝
모델 수준 최적화의 첫 번째 범주는 모델 크기를 줄이는 압축이다. 모델이 작아지면 메모리 사용량이 줄고 속도가 빨라진다. 트레이드오프는 모델 품질 저하 가능성이다.
양자화(Quantization) — 가장 실용적인 기법. 모델 정밀도를 낮춰 메모리 사용량과 대역폭 소모를 줄인다. FP32 → FP16으로 줄이면 메모리가 절반이 된다. MBU 계산식에서 파라미터당 바이트 수가 줄수록 소중한 대역폭을 덜 소모한다. 쓰기 쉽고 많은 모델에서 즉시 적용 가능하다는 장점 때문에 단연코 가장 인기 있는 압축 기법이다. 단, 값 하나당 1비트 이하로는 낮출 수 없어 한계가 존재한다.
지식 증류(Knowledge Distillation). 큰 교사 모델의 동작을 따라하도록 작은 학생 모델을 학습시킨다. 더 적은 파라미터로 큰 모델의 동작을 잡아낼 수 있다는 관점에서 출발한다.
프루닝(Pruning). 예측에 기여하지 않는 파라미터를 0으로 설정하거나, 신경망 노드 전체를 제거한다. 두 가지 방식이 있다: 노드 전체 제거(아키텍처 변경·파라미터 수 감소) 또는 파라미터를 0으로 설정(총 파라미터 수 유지, 0이 아닌 파라미터만 감소 → 모델 희소화). 프루닝 후 추가 파인튜닝으로 성능을 회복할 수 있다. Frankle & Carlin(2019)은 프루닝으로 0이 아닌 파라미터를 90% 이상 줄이면서 정확도를 유지한 사례를 보여줬다. 그러나 집필 당시 기준으로 실제 사용 사례가 많지 않다. 원본 아키텍처에 대한 깊은 이해가 필요하고, 희소 모델을 모든 하드웨어가 효율적으로 활용하지 못한다는 한계가 있다.
5. 자기회귀 디코딩 병목 극복
자기회귀 언어 모델은 토큰을 하나씩 순차 생성한다. 토큰 하나당 100ms가 걸리면 100개 토큰 응답에 10초가 걸린다. 여러 모델 API에서 출력 토큰은 입력 토큰보다 약 2~4배 비용이 들며, 애니스케일 실험(Kadous et al., 2023)에 따르면 출력 토큰 하나가 지연 시간에 미치는 영향이 입력 토큰 100개와 맞먹을 수 있다.
5.1 Speculative Decoding(추측 디코딩)
더 빠르지만 성능이 낮은 초안(draft) 모델로 K개 토큰 시퀀스를 먼저 생성하고, 목표 모델이 이를 병렬로 검증·수락한다.
동작 순서: 1. 초안 모델이 K개 토큰 시퀀스를 생성한다 2. 목표 모델이 이 K개 토큰을 병렬로 검증한다 3. 목표 모델이 초안 시퀀스를 왼쪽부터 검증하여, 처음 예측이 엇갈리는 지점 바로 앞까지만 수락한다 4. 목표 모델이 수락한 마지막 위치 바로 다음 토큰을 직접 생성한다
핵심 통찰 세 가지: 1. 검증은 병렬화 가능하지만 생성은 순차적이라 검증이 훨씬 빠르다(디코딩을 프리필 방식으로 전환하는 효과) 2. 약한 초안 모델도 예측하기 쉬운 토큰에서는 높은 수락률을 낸다 3. 디코딩은 메모리 대역폭 제약이라 남는 FLOP을 검증에 활용할 수 있다
수락률과 K 값 선택. 수락률은 도메인에 따라 다르다. 코드처럼 정해진 구조를 따르는 텍스트에서 수락률이 더 높다. K 값이 클수록 목표 모델의 검증 횟수는 줄지만 초안 토큰 수락률도 낮아진다. 초안 모델은 어떤 아키텍처든 될 수 있지만, 목표 모델과 같은 어휘·토크나이저를 쓰는 게 좋다.
실증 사례. 딥마인드는 Chinchilla-70B(집필 당시 논문 기준)의 디코딩을 빠르게 하려고 같은 아키텍처의 40억 파라미터 초안 모델을 학습시켰다(Chen et al., 2023). 초안 모델은 목표 모델보다 8배 빠르게 토큰을 생성한다(토큰당 1.8ms 대 14.1ms). 결과적으로 응답 품질 저하 없이 전체 응답 지연 시간을 절반 이상 줄였다.
추측 디코딩은 파이토치에서 약 50줄의 코드로 구현 가능하며, vLLM·TensorRT-LLM·llama.cpp 같은 주요 추론 프레임워크에 이미 내장되어 있다. 비교적 구현이 쉽고 모델 품질을 바꾸지 않아 최근 큰 주목을 받고 있다.
5.2 참조 기반 추론
추측 디코딩과 유사하나, 추가 모델 없이 입력 컨텍스트에서 직접 초안 토큰을 가져온다. 핵심 과제는 각 디코딩 단계에서 컨텍스트에서 가장 관련성 높은 텍스트 구간을 찾는 알고리즘이다. Yang et al.(2023)은 해당 활용 사례에서 2배의 생성 속도 향상을 달성했다고 보고한다. 검색 시스템·코딩·멀티 턴 대화처럼 컨텍스트와 출력 사이에 상당한 중복이 있는 시나리오에서만 유용하다.
5.3 병렬 디코딩 — Medusa(메두사)
순차적 의존성을 우회하는 접근법이다. 기존 시퀀스가 주어졌을 때 다음 여러 토큰을 동시에 생성하려 시도한다. 이게 가능한 이유는 기존 시퀀스만 알아도 다음 몇 개 토큰을 충분히 예측할 수 있는 경우가 많기 때문이다.
- 룩어헤드 디코딩(Lookahead Decoding, Fu et al., 2024): 같은 디코더로 병렬 토큰을 생성하고, 야코비 방법(Jacobi method)으로 검증한다. 검증 실패 토큰만 재생성하며, 생성된 모든 토큰이 검증을 통과할 때까지 정제한다.
- Medusa(Cai et al., 2024): 원본 모델에 여러 디코딩 헤드를 추가한다. 각 헤드는 특정 위치의 미래 토큰을 예측하도록 학습된 작은 신경망 레이어다. 트리 기반 어텐션 메커니즘으로 후보 토큰들을 검증·통합한다. 엔비디아는 Medusa가 HGX H200 GPU에서 Llama 3.1 토큰 생성을 최대 1.9배 향상시켰다고 밝혔다(Eassa et al., 2024 — 집필 당시 논문 기준).
6. 어텐션 메커니즘 최적화 — KV 캐시와 플래시 어텐션
어텐션은 트랜스포머의 핵심이자 가장 큰 연산·메모리 병목이다.
KV 캐시의 작동과 크기. 토큰 xₜ₊₁을 생성할 때 이전 모든 토큰의 키(K)·값(V) 벡터를 다시 계산하는 대신 저장해 재사용한다. KV 캐시는 학습이 아닌 추론할 때만 사용된다(학습 시에는 시퀀스의 모든 토큰을 미리 알아 한꺼번에 처리 가능).
KV 캐시 크기 공식:
KV 캐시 = 2 × B × S × L × H × M
B: 배치 크기
S: 시퀀스 길이
L: 트랜스포머 레이어 개수
H: 모델 차원
M: 값당 바이트 (FP16 = 2, FP32 = 4)
예: 라마 2-13B(레이어 40개, 차원 5,120), 배치 32, 시퀀스 길이 2,048, FP16
→ 2 × 32 × 2,048 × 40 × 5,120 × 2 = 약 54 GB
어텐션 연산량은 시퀀스 길이의 제곱에 비례(O(n²))하는 반면 KV 캐시 크기는 선형으로 증가한다. 구글 논문에 따르면 멀티헤드 어텐션을 가진 500B+ 모델에서 배치 크기 512, 컨텍스트 길이 2048일 때 KV 캐시가 3TB에 달하며, 이는 모델 가중치 크기의 3배에 해당한다(Pope et al., 2022).
KV 캐시를 줄이는 어텐션 재설계.
| 기법 | 원리 | 효과 |
|---|---|---|
| 멀티 쿼리 어텐션(MQA, Shazeer, 2019) | 쿼리 헤드들이 단 하나의 키-값 쌍 세트를 공유 | KV 캐시 크게 절감 |
| 그룹 쿼리 어텐션(GQA, Ainslie et al., 2023) | 쿼리 헤드들을 그룹으로 나눠 그룹 내에서만 공유 | MQA보다 유연하게 조절 가능 |
| 크로스 레이어 어텐션(Brandon et al., 2024) | 인접 레이어들이 키-값 벡터를 공유 | 레이어 3개 공유 시 KV 캐시 1/3 감소 |
| 로컬 윈도우 어텐션(Beltagy et al., 2020) | 인접한 고정 크기 창 안의 토큰에만 어텐션 적용 | 유효 시퀀스 길이 감소 |
Character.AI(2024)는 평균 180개 메시지 대화 기록이 누적되는 환경에서, 멀티 쿼리 어텐션 + 로컬·글로벌 어텐션 번갈아 사용 + 크로스 레이어 어텐션 세 가지를 조합해 KV 캐시를 20배 이상 줄였다.
페이지드 어텐션(Paged Attention) — vLLM. KV 캐시를 연속적이지 않은 블록으로 나누어 메모리 단편화를 줄이고 유연하게 공유한다(Kwon et al., 2023). vLLM이 이 방식으로 LLM 서빙 효율을 크게 개선했다.
다른 KV 캐시 최적화 기법으로는 KV 캐시 양자화(Hooper et al., 2024; Kang et al., 2024), 적응형 KV 캐시 압축(Ge et al., 2023), 선택적 KV 캐시(Liu et al., 2024)가 있다.
FlashAttention(플래시 어텐션). 어텐션 점수를 계산하는 커널을 하드웨어 메모리 계층에 맞게 최적화한다. 행렬 곱·마스킹·소프트맥스·드롭아웃·다시 행렬 곱이라는 여러 연산을 하나의 커널로 융합해 메모리 접근 횟수를 줄인다. 원래 엔비디아 A100 GPU용으로 개발됐으며(Dao et al., 2022), 이후 H100용 FlashAttention-3도 나왔다(Shah et al., 2024).
잘못된 이해:
"KV 캐시만 있으면 롱 컨텍스트 처리에 문제없다"
올바른 이해:
KV 캐시 크기는 하드웨어 저장 공간에 제한된다. 롱 컨텍스트 처리 시
KV 캐시 크기 자체가 메모리 병목이 될 수 있어,
GQA·크로스 레이어 어텐션·페이지드 어텐션 등 추가 최적화가 필요하다.
7. 커널과 컴파일러
커널(Kernel). GPU·TPU 같은 특정 하드웨어 가속기에 맞춰 최적화된 특수 코드다. 보통 CUDA(엔비디아)·Triton(오픈AI 개발 맞춤 커널 작성 언어)·ROCm(AMD, 엔비디아 독점 CUDA에 맞서는 오픈 소스 대안) 같은 저수준 언어로 작성된다.
커널 최적화의 네 가지 일반 기법: 1. 벡터화 — 루프에서 데이터를 하나씩 처리하는 대신, 메모리에서 연속으로 배치된 여러 데이터를 동시에 처리해 I/O 연산 감소 2. 병렬화 — 입력 배열을 여러 코어·스레드에서 동시에 처리할 수 있는 독립 덩어리로 분할 3. 루프 타일링 — 하드웨어의 메모리 레이아웃과 캐시에 맞게 루프의 데이터 접근 순서 최적화(CPU 최적화 패턴이 GPU에서는 잘 안 될 수 있음) 4. 연산자 융합 — 여러 연산자를 단일 패스로 결합해 불필요한 메모리 접근 제거. 모델의 특정 연산자와 아키텍처 이해가 더 깊이 필요함
커널은 하드웨어 아키텍처에 최적화된다. 새로운 하드웨어 아키텍처가 나올 때마다 새 커널 개발이 필요하다. 많은 AI 기업이 자체 커널을 영업 기밀로 여긴다.
컴파일러(Compiler). 모델 스크립트를 하드웨어 호환 언어로 변환(로어링, lowering)하는 도구다. 로어링 과정에서 대상 하드웨어에 맞는 전용 커널로 연산을 최적화한다. 주요 컴파일러: Apache TVM·torch.compile·TensorRT(엔비디아)·XLA(구글, OpenXLA 오픈 소스 버전 있음)·MLIR.
파이토치 추론 최적화 사례. 파이토치 팀이 라마-7B의 처리량을 단계적으로 개선한 사례(PyTorch, 2023, A100-80GB에서 실험): 1. torch.compile로 모델을 더 효율적인 커널로 컴파일 2. 모델 가중치를 INT8로 양자화 3. 모델 가중치를 INT4로 한 번 더 양자화 4. 추측 디코딩 추가
단계를 거칠수록 처리량이 누적 향상되었다.
8. 추론 서비스 최적화 — 배칭과 프롬프트 캐싱
서비스 수준 최적화는 모델을 변경하지 않고 운영 방식만 바꿔 효율을 높인다. 출력 품질도 바뀌지 않아야 한다는 점이 모델 수준 최적화와의 핵심 차이다.
배치 처리 세 가지 방식.
정적 배치 처리(static batching): 정해진 수의 요청이 차면 처리. 모든 자리가 찰 때까지 기다리는 버스처럼, 마지막 요청이 올 때까지 모두 기다려야 한다.
동적 배치 처리(dynamic batching): 최대 대기 시간을 설정해, 배치가 찼거나 시간이 초과하면 처리. 배치가 항상 꽉 차 있지 않을 수 있어 연산 자원 낭비 가능성이 있다.
연속 배치 처리(continuous batching, 인플라이트 배칭): Orca 논문(Yu et al., 2022)에서 소개. 배치 내 응답이 끝나는 대로 즉시 반환하고 빈 자리에 새 요청을 채운다. 한 응답 10개 토큰, 다른 응답 1,000개 토큰이 같은 배치에 있을 때 짧은 응답이 긴 응답 완료를 기다리는 문제를 해결한다. 링크드인 AI 팀은 TTFT·TPOT를 조금 희생해 처리량을 2~3배 올릴 수 있었다고 밝혔다.
프리필·디코딩 분리. 두 단계를 서로 다른 인스턴스(GPU)에 할당해 리소스 경쟁을 제거한다. DistServe(Zhong et al., 2024)·Inference Without Interference(Hu et al., 2024) 연구는 지연 시간 요구를 지키면서도 처리 요청량을 크게 늘릴 수 있음을 보여준다. 노드 내 NVLink 같은 고대역폭 연결 덕분에 통신 오버헤드가 크지 않다. 인스턴스 비율 가이드:
- 입력 시퀀스가 길고 TTFT를 우선시 → 프리필:디코딩 = 2:1~4:1
- 입력 시퀀스가 짧고 TPOT를 우선시 → 1:2~1:1
프롬프트 캐싱(Prompt Caching). 여러 프롬프트에 공통으로 겹치는 부분(특히 시스템 프롬프트)을 캐시에 저장해 한 번만 처리한다. 컨텍스트 캐시·프리픽스 캐시라고도 불린다. 시스템 프롬프트가 1,000 토큰이고 하루 100만 건의 API 호출이 있다면 약 10억 개의 반복 입력 토큰 처리를 절약한다.
집필 당시 기준 앤트로픽은 최대 90% 비용 절감·최대 75% 지연 시간 감소를 제공한다. 구글 제미나이는 캐시된 입력 토큰에 일반 대비 75% 할인을 제공(단 캐시 저장에 추가 비용). 실측 사례(앤트로픽 데이터 기준):
| 사용 사례 | 캐싱 미적용 지연(TTFT) | 캐싱 적용 지연 | 비용 절감 |
|---|---|---|---|
| 책과 대화하기 | 11.5초 | 2.4초 (-79%) | -90% (10만 토큰 캐시) |
| 다수 예시 프롬프트 | 1.6초 | 1.1초 (-31%) | -86% (10,000 토큰) |
| 멀티 턴 대화 (긴 시스템 프롬프트) | ~10초 | ~2.5초 (-75%) | -53% |
단, 프롬프트 캐시 자체가 메모리 공간을 차지하는 비용이 있다. llama.cpp도 프롬프트 캐싱을 지원하지만, 집필 당시 기준으로 전체 프롬프트만 캐시하고 같은 채팅 세션의 질의에서만 작동했다.
적용 판단 — 프롬프트 캐싱은 긴 겹치는 프롬프트나 멀티 턴 대화에 효과적이다. KV 캐시는 롱 컨텍스트 처리에 효과적이다. 짧은 컨텍스트 단발성 요청에서는 두 기법 모두 효과가 제한적이다.
9. 병렬화 전략
다수의 가속기를 협력시켜 대형 모델을 빠르고 저렴하게 처리하는 전략이다.
복제 병렬 처리(Replica Parallelism). 모델 복제본을 여러 개 만들어 요청을 분산한다(학습에서는 데이터 병렬 처리라 부름). 구현이 가장 단순하지만, 단일 머신에 올라가지 않는 대형 모델에는 적용 불가다. 엄격한 지연 시간 요구사항이 있는 경우 가장 적합하다.
텐서 병렬 처리(Tensor Parallelism). 행렬 곱셈 같은 텐서 연산을 여러 장치에 걸쳐 분할해 병렬 실행한다(연산자 내 병렬 처리라고도 함). 단일 머신에 맞지 않는 대형 모델 서빙이 가능해지고 지연 시간이 줄어드는 장점이 있다. 추가 통신 오버헤드로 지연 감소 효과가 줄어들 수 있다. 추론에서 가장 일반적인 모델 병렬 처리 방식이다.
파이프라인 병렬 처리(Pipeline Parallelism). 모델 연산을 여러 독립 단계로 나누어 각 단계를 다른 장치에 할당한다. 하나의 배치가 더 작은 마이크로 배치로 분할되어 파이프라인을 흐른다. 처리량을 높이는 데 유리하지만 단계 간 통신 오버헤드 때문에 지연 시간이 증가한다. 엄격한 지연 요구사항에서는 복제 병렬 처리가 더 적합하며, 학습 시에는 파이프라인 병렬 처리가 일반적으로 선호된다.
컨텍스트·시퀀스 병렬 처리. 긴 입력 시퀀스 처리를 더 효율적으로 만들기 위해 개발됐다. - 컨텍스트 병렬 처리: 입력 시퀀스 자체를 여러 디바이스로 분할 (입력 전반부 → 머신1, 후반부 → 머신2) - 시퀀스 병렬 처리: 전체 입력에 필요한 연산자들(어텐션·피드포워드)을 여러 머신으로 분할
추론 서비스 제공업체별 품질 차이. 같은 모델이라도 추론 서비스 제공업체마다 최적화 방식이 다를 수 있어 품질 차이가 발생한다. Cerebras(2024) 실험 보고서에 따르면 Llama 3.1-70B와 3.1-8B를 여러 업체로 서빙했을 때 MMLU·GPQA·MGSM·MATH·DROP 등 벤치마크에서 미세한 차이가 나타났다.
핵심 개념 정리
| 기법 | 범주 | 핵심 효과 | 주요 트레이드오프 |
|---|---|---|---|
| 양자화 | 모델 압축 | 메모리 절감·속도 향상 | 정밀도 저하 가능성 |
| 프루닝 | 모델 압축 | 희소 모델 생성 | 하드웨어 호환성, 높은 구현 난이도 |
| 지식 증류 | 모델 압축 | 사용 목적 맞춤 소형 모델 | 교사 모델 의존, 학습 비용 |
| 추측 디코딩 | 디코딩 가속 | 지연 시간 절반 이상 감소 | 초안 모델 수락률 의존 |
| 참조 기반 추론 | 디코딩 가속 | 추가 모델 불필요 | 중복 컨텍스트 시나리오에만 유용 |
| 병렬 디코딩(Medusa) | 디코딩 가속 | 최대 1.9배 향상 | 구현 복잡도 높음 |
| KV 캐시 | 어텐션 최적화 | 반복 계산 제거 | 메모리 대규모 사용 |
| GQA·MQA | 어텐션 최적화 | KV 캐시 크기 절감 | 아키텍처 수정 필요(학습·파인튜닝 시에만 적용) |
| 페이지드 어텐션 | 메모리 관리 | 단편화 제거·유연한 공유 | vLLM 등 프레임워크 의존 |
| 플래시 어텐션 | 커널 최적화 | 어텐션 연산 속도 향상 | 하드웨어별 재구현 필요 |
| 연속 배치 처리 | 서비스 최적화 | 처리량 2~3배 향상 | 구현 복잡도 증가 |
| 프리필·디코딩 분리 | 서비스 최적화 | TTFT·TPOT 동시 개선 | 인스턴스 간 통신 오버헤드 |
| 프롬프트 캐싱 | 서비스 최적화 | 비용·지연 시간 대폭 절감 | 캐시 메모리 비용, 단발성 요청에 비효과적 |
| 텐서 병렬 처리 | 병렬화 | 대형 모델 서빙·지연 감소 | 통신 오버헤드 |
| 파이프라인 병렬 처리 | 병렬화 | 처리량 향상 | 지연 시간 증가 (학습에 권장) |
| 복제 병렬 처리 | 병렬화 | 지연 시간 낮음, 구현 단순 | 단일 머신 용량 초과 모델 불가 |
실무 체크리스트
- [ ] 추론 병목이 연산 제약인지 메모리 대역폭 제약인지 먼저 진단했는가(루프라인 차트·산술 강도 활용)?
- [ ] GPU 활용률이 아닌 MFU·MBU로 실질 효율을 측정하고 있는가?
- [ ] 지연 시간을 TTFT와 TPOT로 분리해 측정하고 있는가?
- [ ] 지연 시간을 평균이 아닌 p50·p90·p95·p99 백분위수로 모니터링하고 있는가?
- [ ] CoT·에이전트 워크플로에서 사용자가 보는 실제 TTFT(Time to Publish)를 측정하고 있는가?
- [ ] 지연 시간 요구가 느슨한 작업(합성 데이터·보고서 생성 등)에 배치 API를 활용하고 있는가?
- [ ] 양자화(INT8·INT4) 적용 시 모델 품질 저하가 허용 범위 안에 있는가?
- [ ] KV 캐시 크기가 GPU 메모리 용량 제한에 걸리는지 공식으로 계산했는가?
- [ ] 롱 컨텍스트 애플리케이션에서 그룹 쿼리 어텐션·페이지드 어텐션 적용을 검토했는가?
- [ ] 시스템 프롬프트가 긴 서비스에서 프롬프트 캐싱 도입으로 절감 규모를 추정했는가?
- [ ] 연속 배치 처리(인플라이트 배칭)로 처리량 개선 여지가 있는지 확인했는가?
- [ ] 프리필·디코딩 분리 시 워크로드 특성(입력 길이·TTFT vs TPOT 우선순위)에 맞게 인스턴스 비율을 설정했는가?
- [ ] 지연 시간 요구사항에 따라 복제/텐서/파이프라인 병렬 처리 중 적합한 전략을 선택했는가?
- [ ] 추론 서비스 제공업체마다 같은 모델도 최적화 방식에 따라 품질 차이가 있음을 인지하고 있는가?
연습문제
-
개념. 트랜스포머 기반 언어 모델의 프리필 단계가 연산 제약이고 디코딩 단계가 메모리 대역폭 제약인 이유를, 각 단계의 처리 방식(병렬 vs 순차)과 가속기의 메모리 계층 구조를 연결해 설명하라.
-
계산. 라마 2-13B(레이어 40개, 차원 5,120)로 배치 크기 16, 시퀀스 길이 4,096, FP16을 사용할 때 KV 캐시에 필요한 메모리를 공식을 사용해 계산하고, GPU 메모리 80 GB 기준으로 가용 여부를 판단하라. 모델 가중치 메모리(13B 파라미터, FP16)도 함께 고려하라.
-
비교. 정적·동적·연속 배치 처리의 트레이드오프를 지연 시간과 처리량 관점에서 비교하고, 고객 대면 챗봇과 야간 보고서 생성 작업에 각각 어떤 방식이 더 적합한지 이유와 함께 설명하라.
-
분석. 추측 디코딩에서 초안 토큰이 하나도 수락되지 않는 최악의 경우에도 목표 모델이 최소 하나의 토큰을 생성한다. 이 과정에서 지연 시간이 순수 자기회귀 디코딩보다 오히려 늘어날 수 있는 조건은 무엇이며, "디코딩은 메모리 대역폭 제약이라 남는 FLOP을 검증에 활용할 수 있다"는 통찰이 이 위험을 어떻게 완화하는지 설명하라.
-
설계. 평균 대화 기록 200 메시지, 시스템 프롬프트 2,000 토큰, 하루 50만 건 API 호출을 처리하는 멀티 턴 챗봇 서비스를 최적화한다. 이 장에서 다룬 기법 중 우선 적용할 3가지를 고르고 각각의 기대 효과와 구현 난이도를 표로 정리하라. 각 기법 선택 이유를 이 서비스의 특성(높은 반복 프롬프트, 대화 기록 누적, 고빈도 요청)과 연결해 설명하라.
최신 동향 (2026-05 기준)
최신 동향 (검증 2026-05-21) — 추론 최적화 스택이 빠르게 재편됐다. INT4·AWQ 양자화와 Speculative Decoding(초안 모델로 가속)이 production 표준으로 자리잡았고, vLLM이 서빙 사실상 표준 프레임워크로 부상했다. SGLang은 복잡한 다단계 프롬프트·에이전트 워크플로에서 vLLM 대비 처리량 우위가 보고되고 있다. FlashAttention-3이 H100에 최적화되어 메모리 접근 효율을 추가 개선했다. 책의 원리(KV 캐시·배치·양자화·병렬화 개념)는 그대로 유효하다.
부록 A. 용어 사전
| 한글 | 영문 | 의미 |
|---|---|---|
| 추론 | Inference | 학습된 모델에 입력을 넣어 결과를 얻는 과정. 순전파만 실행한다 |
| 추론 서버 | Inference Server | 운영 환경에서 모델 추론을 실행하는 구성 요소 |
| 지연 시간 | Latency | 요청 시점부터 완전한 응답을 받기까지 걸리는 시간 (TTFT + TPOT × 출력 토큰 수) |
| 처리량 | Throughput | 서비스가 초당 생성하는 출력 토큰 수(tokens/s). 비용과 직결 |
| 첫 토큰까지 걸리는 시간 | TTFT (Time To First Token) | 프리필 단계 완료 시점. 사용자가 처음 응답을 보기까지 체감 대기 시간 |
| 출력 토큰당 시간 | TPOT (Time Per Output Token) | 첫 토큰 이후 각 토큰 생성 속도. 스트리밍 유창성을 결정 |
| 공개까지의 시간 | Time to Publish | CoT·에이전트 방식에서 사용자가 실제로 보는 첫 토큰까지의 시간 |
| 굿풋 | Goodput | SLO를 만족하는 초당 요청 수. 처리량만으로 파악하기 어려운 사용자 경험 반영 |
| 모델 FLOPs 활용률 | MFU (Model FLOPs Utilization) | 이론적 최대 FLOP/s 대비 실제 토큰 처리량 비율 |
| 모델 대역폭 활용률 | MBU (Model Bandwidth Utilization) | 이론적 대역폭 대비 실제 사용 대역폭 비율 |
| 산술 강도 | Arithmetic Intensity | 메모리 1바이트 접근당 산술 연산 횟수. 연산 제약 vs 메모리 제약 구분 기준 |
| KV 캐시 | KV Cache | 디코딩 시 이전 토큰의 Key·Value 벡터를 저장해 반복 계산을 제거하는 메모리 구조 |
| 양자화 | Quantization | 모델 가중치 정밀도(FP32→FP16·INT8·INT4)를 낮춰 메모리·대역폭 소모를 줄이는 기법 |
| 추측 디코딩 | Speculative Decoding | 소형 초안 모델로 K개 토큰을 먼저 생성 후 목표 모델이 병렬 검증하는 지연 감소 기법 |
| 페이지드 어텐션 | Paged Attention | KV 캐시를 불연속 블록으로 관리해 메모리 단편화를 줄이는 방식 (vLLM) |
| 플래시 어텐션 | FlashAttention | 어텐션 연산을 하드웨어 메모리 계층에 맞게 커널 단위로 융합해 속도를 높이는 기법 |
| 그룹 쿼리 어텐션 | GQA (Grouped Query Attention) | 쿼리 헤드를 그룹으로 나눠 그룹 내 키-값 공유로 KV 캐시를 줄이는 어텐션 재설계 |
| 연속 배치 처리 | Continuous Batching | 완료된 응답 즉시 반환·빈 자리 즉시 채움으로 처리량을 높이는 배치 방식 |
| 로어링 | Lowering | 모델 스크립트를 하드웨어 호환 언어로 변환하는 컴파일 과정 |
부록 B. 핵심 비교표
연산 제약 vs 메모리 대역폭 제약
| 구분 | 연산 제약 (compute-bound) | 메모리 대역폭 제약 (memory bandwidth-bound) |
|---|---|---|
| 병목 | 수행해야 할 연산량 | 메모리↔프로세서 데이터 전송 속도 |
| 해당 단계 | 프리필 (입력 전체 병렬 처리) | 자기회귀 디코딩 (토큰 1개씩 순차 생성) |
| 지표 | MFU 높음, MBU 낮음 | MFU 낮음, MBU 높음 |
| 주요 대응 기법 | 연산 최적화, 컴파일러, 더 높은 FLOP/s 칩 | 양자화, KV 캐시 축소, 추측 디코딩, 더 넓은 대역폭 칩 |
배치 처리 방식 비교
| 방식 | 지연 시간 | 처리량 | 문제점 | 적합 시나리오 |
|---|---|---|---|---|
| 정적 배치 (static) | 높음 (마지막 요청 대기) | 보통 | 짧은 응답이 긴 응답 완료 대기 | 오프라인 일괄 작업 |
| 동적 배치 (dynamic) | 중간 (최대 대기 시간 설정) | 중간 | 배치가 항상 꽉 차지 않을 수 있음 | 준실시간 처리 |
| 연속 배치 (continuous) | 낮음 | 2~3배 향상 | 구현 복잡도 증가 | 고객 대면 실시간 서비스 |
병렬화 전략 비교
| 전략 | 지연 시간 | 처리량 | 제약 | 권장 사용 |
|---|---|---|---|---|
| 복제 병렬 처리 | 낮음 | 선형 확장 | 단일 머신에 올라가는 모델만 | 엄격한 지연 요구, 추론 |
| 텐서 병렬 처리 | 낮음~중간 | 좋음 | 통신 오버헤드 | 대형 모델 서빙 (추론 권장) |
| 파이프라인 병렬 처리 | 높음 | 좋음 | 단계 간 통신 오버헤드 | 대형 모델 학습 권장 |
| 컨텍스트·시퀀스 병렬 처리 | 변동 | 변동 | 구현 복잡 | 긴 입력 시퀀스 처리 |
모델 압축 기법 비교
| 기법 | 구현 난이도 | 현장 채택률 | 주요 한계 |
|---|---|---|---|
| 양자화 | 낮음 | 매우 높음 | 비트당 1비트 미만 불가 |
| 지식 증류 | 중간 | 높음 | 교사 모델·학습 비용 필요 |
| 프루닝 | 높음 | 낮음 | 하드웨어 희소 모델 지원 불균등 |
부록 C. 추천 참고 자료
명명 자원 (생존 확인 2026-05-21)
| 자료 | 링크 |
|---|---|
| vLLM 공식 문서 (페이지드 어텐션·추론 서빙) | docs.vllm.ai |
| SGLang 공식 저장소 (구조화 생성·에이전트 워크플로) | github.com/sgl-project/sglang |
| FlashAttention 공식 저장소 | github.com/Dao-AILab/flash-attention |
| Speculative Decoding 원논문 (Leviathan et al., 2022) | arxiv.org/abs/2211.17192 |
| AWQ 양자화 논문 | arxiv.org/abs/2306.00978 |
| Hugging Face 문서 (양자화·최적화) | huggingface.co/docs |
책 내 연계
| 자료 | 설명 |
|---|---|
| 책 2장 | 트랜스포머 아키텍처(프리필·디코딩 단계)와 KV 캐시의 기반이 되는 어텐션 메커니즘 |
| 책 7장 | 양자화·수치 표현 방식의 세부 내용 |
| 책 8장 | 지식 증류의 학습 방식과 합성 데이터 관계 |
| 책 10장 | 추론 최적화 기법들을 통합한 AI 시스템 구축 |
핵심 논문
| 논문 | 기여 |
|---|---|
| Williams et al. (2009) Roofline | 연산 제약 vs 메모리 대역폭 제약 구분 프레임워크 |
| Chowdhery et al. (2022) PaLM | MFU 용어 최초 정의 |
| Dao et al. (2022) FlashAttention | 어텐션 커널 융합 — 메모리 접근 횟수 절감 |
| Kwon et al. (2023) vLLM | KV 캐시 페이지드 어텐션 — 불연속 블록 할당 단편화 제거 |
| Yu et al. (2022) Orca | 연속 배치 처리(인플라이트 배칭)의 이론적 토대 |
| Chen et al. (2023) Speculative Decoding | Chinchilla-70B 기준 지연 절반 이상 감소 실증 (논문 발표 당시 기준) |
부록 D. 연습문제 풀이
-
(프리필은 입력 전체를 병렬 처리해 연산 제약, 디코딩은 토큰 하나씩 순차 생성으로 매 스텝 전체 모델 가중치를 메모리에서 읽어야 해 메모리 대역폭 제약이다.) 프리필 단계는 입력 토큰 전체에 대해 행렬 곱셈을 한 번에 수행한다. 처리해야 할 연산량이 많고 GPU의 병렬 연산 코어를 최대한 활용하므로 연산 제약(compute-bound)이다. MFU가 높고 MBU가 낮다. 반면 디코딩 단계는 토큰을 한 번에 하나씩 자기회귀 방식으로 생성하며, 매 스텝마다 GPU HBM에서 전체 모델 가중치를 연산 유닛으로 불러와야 한다. 이 데이터 전송 속도가 병목이 되므로 메모리 대역폭 제약(memory bandwidth-bound)이다. MFU가 낮고 MBU가 높다.
-
(KV 캐시 ≈ 53.7 GB, 모델 가중치 ≈ 26 GB, 합산 ≈ 79.7 GB — 80 GB GPU에서 가용하지만 활성화 메모리 추가 시 부족 가능.) 공식 KV 캐시 크기 = 2 × B × S × L × H × M에 B=16, S=4096, L=40, H=5120, M=2(FP16이므로 2바이트)를 대입하면 2 × 16 × 4096 × 40 × 5120 × 2 = 약 53.7 GB다. 모델 가중치는 13B 파라미터 FP16 기준 약 26 GB다. 두 합산이 약 79.7 GB로 80 GB GPU 용량에 거의 근접한다. 실제 운영에서 활성화 메모리·프레임워크 오버헤드까지 더하면 부족해지므로, 그룹 쿼리 어텐션(GQA)으로 KV 캐시를 절감하거나 시퀀스 길이를 줄여야 한다.
-
(지연 시간은 정적 > 동적 > 연속 순으로 개선되고, 처리량은 연속 > 동적 > 정적 순이다. 고객 대면 챗봇에는 연속 배치, 야간 보고서에는 정적 또는 동적 배치가 적합하다.) 정적 배치는 정해진 수가 찰 때까지 기다리므로 첫 요청이 마지막 요청 도착까지 지연되어 지연 시간이 가장 높다. 동적 배치는 최대 대기 시간을 설정해 지연을 제한하지만 배치가 항상 꽉 차지 않아 처리 효율이 중간이다. 연속 배치 처리는 응답이 완료된 즉시 새 요청을 채워 처리량을 2~3배 높이고 짧은 응답이 긴 응답을 기다리는 문제를 해결한다. 고객 대면 챗봇은 낮은 TPOT가 핵심이므로 연속 배치가 적합하다. 야간 보고서 생성은 지연 시간 제약이 느슨해 정적·동적 배치로 구현 단순성을 유지하는 것이 적합하다.
-
(초안 모델 오버헤드 + 검증 시간이 목표 모델 단독 1스텝보다 커지는 경우 지연이 늘어난다. 디코딩의 메모리 대역폭 제약 특성이 이를 완화한다.) 추측 디코딩에서 최악의 경우(수락 0개)에도 목표 모델은 검증 패스에서 최소 1개 토큰을 직접 생성한다. 그러나 초안 모델이 K개 토큰을 생성하는 시간과 목표 모델이 K개를 한꺼번에 검증하는 시간의 합이, 목표 모델이 단순 1개 토큰을 자기회귀 생성하는 시간보다 길면 지연이 오히려 늘어난다. 이는 초안 모델 수락률이 극도로 낮거나 K가 너무 클 때 발생한다. "디코딩은 메모리 대역폭 제약이라 남는 FLOP을 검증에 활용할 수 있다"는 통찰이 이 위험을 완화한다. 디코딩 시 GPU의 연산 코어 상당수가 메모리 전송 대기로 유휴 상태다. 이 여유 FLOP으로 병렬 검증을 수행하므로 검증의 추가 비용이 매우 낮다. K를 동적으로 조정하거나 도메인 적합 초안 모델을 선택해 수락률을 높이면 추가 완화가 가능하다.
-
(프롬프트 캐싱, 연속 배치 처리, 텐서 병렬 처리를 우선 적용한다.)
| 기법 | 기대 효과 | 구현 난이도 | 이 서비스와의 연결 |
|---|---|---|---|
| 프롬프트 캐싱 | 2,000 토큰 시스템 프롬프트 × 50만 건 = 약 10억 토큰 절감. 비용 최대 90%, 지연 최대 75% 감소(앤트로픽 기준) | 낮음 — 벤더 API 파라미터 설정으로 적용 | 시스템 프롬프트 2,000 토큰이 고정되어 모든 질의에 반복. 대화 기록 캐시로 멀티 턴 지연 추가 절감 |
| 연속 배치 처리 | 처리량 2~3배 향상으로 같은 GPU로 더 많은 동시 요청 처리 → 비용 절감 | 중간 — vLLM 등 기존 프레임워크 활용 시 낮음 | 하루 50만 건 고빈도 요청에서 GPU 활용률 극대화. 응답 길이가 다양한 대화에서 효과 큼 |
| 텐서 병렬 처리 | 대형 모델을 여러 GPU에 분산해 지연 시간 감소, 단일 GPU 용량 초과 모델 서빙 가능 | 높음 — 장치 간 통신 설정 및 메모리 배분 조정 필요 | 200 메시지 누적 대화 기록으로 KV 캐시가 커질수록 단일 GPU 용량 부족 가능. 텐서 병렬 처리로 분산 |
멀티 턴 대화는 대화 기록이 누적돼 반복 프롬프트가 많고 시스템 프롬프트가 고정되어 있어 프롬프트 캐싱 효과가 가장 크다. 50만 건의 고빈도 요청은 연속 배치 처리로 GPU 활용률을 극대화하고, 대화 기록 누적으로 KV 캐시가 커지는 상황에서는 텐서 병렬 처리로 지연 시간을 추가로 줄인다.
클릭하거나 Space를 눌러 뒤집기